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REMARKS 

Claims 1-20 and 35-38 are pending in the application. 
Claim Rejections Under 35 U.S.C. §103 

In the above Office Action the Examiner has rejected claims 1-20 and 35-38 
under 35 U.S.C. § 103(a) as being unpatentable over Eydelman (U.S. Patent Application 
Publication No. 2002/0007420) in view of Wang et al. (U.S. Patent No. 7,039,037). 
Applicant respectfully traverses the outstanding rejections for the reasons discussed 
below. 

With respect to claim 1, the Examiner acknowledges that Eydelman does not 

teach generating, at the application, a first input notification determinative of an operative 

mode of the protocol stack. The Examiner also acknowledges that Eydelman does not 

teach switching, responsive to the first input notification, the protocol stack from 

operation in the push mode to operation in the pull mode. However, the Examiner 

alleges that Wang describes these aspects of the method of claim 1 : 

"Wang teaches generating, at the application (WAP controller), a first input 
notification (request) determinative of an operative mode of the protocol stack 
(requesting a service)(Col 9 lines 15-23); and switching, responsive to the first 
input notification, the protocol stack from operation in the push mode to operation 
in a pull mode (Col 9 lines 15-32, the pull mode is initiated by a WAP device 
requesting a service or information from a server, therefore if the system is 
currently in a push mode and receives a request from WAP device, the system 
will switch from the push more [sic] to the pull mode in response to the request)." 
(Final Office Action, Page 3) 

Applicant first addresses the Examiner's contention that "Wang teaches 
generating, at the application (WAP controller), a first input notification (request) 
determinative of an operative mode of the protocol stack (requesting a service)(Col 9 
lines 15-23)". Applicant respectfully disagrees that the cited portion of Wang describes 
generation by the WAP controller (allegedly corresponding to the claimed application) of 
any sort of "notification determinative of an operative mode" of a WAP device by virtue 
of "requesting a service". This is because the WAP device, not the WAP controller, in 
Wang's system operates to request a service ("The pull traffic is initiated by a WAP 
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device requesting a service")(Wang, col. 9, lines 20-21). Accordingly, Wang fails to 
describe generating an input event at an application by virtue of any "request" for a 
service issued by Wang's WAP device, and instead describes a WAP device which is 
itself configured to request a service. 

As noted above, the Examiner further contends that Wang describes "switching, 
responsive to the first input notification, the protocol stack from operation in the push 
mode to operation in a pull mode (Col 9 lines 15-32, the pull mode is initiated by a WAP 
device requesting a service or information from a server...". That is, the Examiner 
argues that the pull-type operation in Wang is initiated by a "WAP device requesting a 
service", and also that "requesting a service" corresponds to the claimed input 
notification. It follows that in the Examiner's view Wang's WAP device, which requests 
a service, is responsible generating the claimed input notification that leads to pull-type 
operation in the WAP device (alleged to correspond to the claimed protocol stack). 
However, Applicant notes that claim 1 requires essentially the opposite approach; namely 
that the notification event be generated by the application ( not the protocol stack), and 
that the protocol stack switches modes in response to the notification event generated by 
the application. Accordingly, Wang effectively teaches away from an approach which 
contemplates that a protocol stack (alleged to correspond to Wang's WAP device) 
switches from a push mode to a pull mode based upon a notification event generated by 
an application (alleged to correspond to Wang's WAP controller). 

Applicant additionally notes that claim 1 recites that a first sequence of data 
packets received by the protocol stack are forwarded to the application in the push mode, 
and that a second sequence of data packets received by the protocol stack are forwarded 
to the application in the pull mode. That is, both the claimed "push mode" and "pull 
mode" contemplate that data packets received by a protocol stack are forwarded to an 
application. It follows that although the term "push traffic" and "pull traffic" are used 
within Wang, Wang does not describe either a "push mode" or a "pull mode" as presently 
claimed since both such modes require a forwarding of previously received data packets 
from a protocol core to an application. In this regard it is clear that Wang does not 
describe forwarding sequences of data packets received by the WAP device to the WAP 
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controller. For example, during push operation of the Wang system, "push traffic" 
generated by an external server is provided to the WAP device and there exists no 
indication this traffic is subsequently "forwarded" to the WAP controller. Similarly, 
"pull traffic" is received by a WAP device in Wang system subsequent to the WAP 
device issuing a request, and there is also no indication that this pull traffic is 
subsequently forwarded to the WAP controller. Any alleged teaching by Eydelman of 
the claimed "push mode" and/or "pull mode" is irrelevant in this regard, since the 
combination of Eydelman and Wang could only yield the claimed invention to the extent 
both Eydelman and Wang describe the claimed push and pull modes (which the 
Examiner alleges is the case). 

Finally, even assuming for the sake of argument that Wang describes the 
equivalent of the claimed protocol stack and application, the Eydelman reference clearly 
and unambiguously teaches away from the approach alleged by the Examiner to be 
described by Wang; namely, the determination by an application of a transfer mode (i.e., 
push or pull) through generation of an input notification event. Rather, Eydelman 
describes a system in which an opposite approach is used, i.e., transport providers 
allegedly corresponding to the claimed "protocol stack" decide which type of transfer 
mode to use. See, e.g., Eydelman at [0029] - [0030]. Accordingly, the Examiner's 
combination of Eydelman and Wang is clearly improper and would not yield an operative 
system. 

Applicant respectfully requests consideration of the remarks herein prior to 
further examination of the above-identified application. The undersigned would of 
course be available to discuss the present application with the Examiner if, in the opinion 
of the Examiner, such a discussion could lead to resolution of any outstanding issues. 
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The Commissioner is hereby authorized to charge any fees that may be due under 
37 CFR §§ 1.16, 1.17 and 1.21, and to credit any overpayment to Deposit Account No. 
50-1283 of the undersigned. 



Dated: May 15, 2009 

Cooley God ward Kronish LLP 
ATTN: Patent Group 
777 6 th Street NW, Suite 1 100 
Washington, DC 20001 

Tel: (858) 550-6000 
Fax: (202) 842-7899 



Respectfully submitted, 

Cooley Godward Kronish llp 
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